home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15030 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.0 KB  |  145 lines

  1. Path: news2.cais.com!news
  2. From: Uncle Snuggles <jphelps@nmaa.org>
  3. Newsgroups: comp.lang.c++
  4. Subject: Multiple Inheritance Pointer Problem
  5. Date: Wed, 03 Apr 1996 02:35:02 -0500
  6. Organization: NMAA
  7. Message-ID: <31622A26.3633@nmaa.org>
  8. NNTP-Posting-Host: 198.6.197.171
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset=us-ascii
  11. Content-Transfer-Encoding: 7bit
  12. X-Mailer: Mozilla 2.0GoldB1 (WinNT; I)
  13.  
  14. I recently used multiple inheritence to help me create a few
  15. socket classes. The details of these socket classes are not
  16. important; however, in my pursual of bugs I found that some
  17. of the pointers to these classes caused core dumps while
  18. other classes seem to work fine. So, as part of my debug
  19. process, I printed out pointers to theses classes before I
  20. passed them around, and then printed these pointers after I
  21. passed them in to various functions, and to my surprise some
  22. of these pointers were off by four bytes! (This took place on
  23. an HP 735, running HP-UX 9.03 -- I think these environment
  24. specs are correct; its late and I'm groggy.)
  25.  
  26. At first I thought this was a compiler bug, so I decided to
  27. encapsulate my class inheritance hierarchy in some code that I
  28. could try on other platforms besides the HP. The code that
  29. follows is what I came up with. I tried this code on a P60 with
  30. MS's 4.0 compiler and got the same pointer problem. Then I
  31. tried the MS 1.52C compiler and got the same problem except
  32. that my pointers were off by 2 bytes (the size of a 16 bit
  33. pointer). I used g++ on the HP and reproduced the same results
  34. as before. I went to my ISP and used g++ on their machine (x86
  35. of some sort) which runs BSDI 2.0 and got the, by then, expected
  36. pointer problem.
  37.  
  38. I'm tempted to think that there really is no problem. My
  39. ignorance about multiple inheritence is most likely the culprit.
  40. Although, a friend of mine looked at Bjorn's C++ book and cited
  41. a spec that sounds like the only thing that depends on the order
  42. of multiple inheritence is the calling order of constructors and
  43. destructors.
  44.  
  45. So, am I crazy to think that three different compilers on two
  46. different platforms all have the same incorrect behavior?
  47. Probably, but I don't have any clue as to why the following
  48. foobar and barfoo classes are referenced differently when 
  49. printed
  50. in their parent foo class. If there's anybody out there who'll
  51. look at the following code and corresponding output (from MFC 
  52. 4.0
  53. on a Pentium 60) and knows what's going on then please clue me 
  54. in.
  55.  
  56. One more thing, the following code actually has a pointer
  57. discrepency of one unless it is compiled with OFF_BY_4 defined
  58. (this define should actually be OFF_BY_2 on 16 bit systems). I 
  59. can
  60. almost make sense of the 4 byte discrepency by thinking that not
  61. all "this"es are created equal, but why a one byte offset?
  62.  
  63.  
  64.  
  65. #include <iostream.h>
  66.  
  67. class foo
  68. {
  69. public:
  70.     void PrintMe(void) { cerr << "this = " << this << endl; }
  71. };
  72.  
  73. class bar
  74. {
  75. #ifdef OFF_BY_4
  76. public:
  77.     int b;
  78. #endif
  79. };
  80.  
  81. class foobar : public foo, public bar
  82. {
  83. #ifdef OFF_BY_4
  84. public:
  85.     int fb;
  86. #endif
  87. };
  88.  
  89. class barfoo : public bar, public foo
  90. {
  91. #ifdef OFF_BY_4
  92. public:
  93.     int bf;
  94. #endif
  95. };
  96.  
  97. main()
  98. {
  99.     foobar fb;
  100.     barfoo bf;
  101.  
  102.     cerr << "&fb = " << &fb << endl;
  103.     fb.PrintMe();
  104.     cerr << "&bf = " << &bf << endl;
  105.     bf.PrintMe();
  106.  
  107.     return(0);
  108. }
  109.  
  110. F:\>cl crap.cpp
  111. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 
  112. 10.00.5270 for 80x86
  113. Copyright (C) Microsoft Corp 1984-1995. All rights reserved.
  114.  
  115. crap.cpp
  116. Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
  117. Copyright (C) Microsoft Corp 1992-1995. All rights reserved.
  118.  
  119. /out:crap.exe
  120. crap.obj
  121.  
  122. F:\>crap
  123. &fb = 0x0012FFAC
  124. this = 0x0012FFAC
  125. &bf = 0x0012FFA8
  126. this = 0x0012FFA9
  127.  
  128. F:\>cl -DOFF_BY_4 crap.cpp
  129. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 
  130. 10.00.5270 for 80x86
  131. Copyright (C) Microsoft Corp 1984-1995. All rights reserved.
  132.  
  133. crap.cpp
  134. Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
  135. Copyright (C) Microsoft Corp 1992-1995. All rights reserved.
  136.  
  137. /out:crap.exe
  138. crap.obj
  139.  
  140. F:\>crap
  141. &fb = 0x0012FFA8
  142. this = 0x0012FFA8
  143. &bf = 0x0012FFA0
  144. this = 0x0012FFA4
  145.